接手一個不熟的 codebase，最花時間的往往不是看某一個檔案，是搞清楚「這個函式跟那個類別到底有沒有關係」，而這種關係通常得靠一路 grep、一路點進去追才拼得出來。今天測的 graphify，要做的就是把這個拼圖過程自動化：掃過一個資料夾（程式碼、文件、設定都算），建成一張知識圖譜，點開任何一個節點都能看到它跟誰有關、憑什麼有關。它的賣點寫得很直接：每一條邊都要說得出根據——哪一行 import、哪一次呼叫、還是文件裡的哪一句話，不是靠向量相似度猜出來的。

設計一個小到可以逐條對照的 codebase

搭了一個五個檔案的小專案：一個 auth.py 定義 validate_token，session.py 真的 import 並呼叫它——這條關係百分之百存在，可以直接對照原始碼。另外兩個類別——LRUCache（快取）和 SlidingWindowCounter（限流）——彼此完全沒有 import、沒有呼叫，純粹是解決類似問題（固定容量、滿了要淘汰）的兩段獨立程式碼。最後加一份 ARCHITECTURE.md，裡面有一句話刻意寫得不夠精準：「這兩個結構都遵循同一種形狀——固定容量、滿了就淘汰最舊的一筆」。這句話套在 LRUCache 身上是對的，套在 SlidingWindowCounter 身上其實不對——它滿的時候是拒絕新請求，不是淘汰舊紀錄，真正的淘汰只跟時間有關，跟「滿不滿」無關。這個落差是我刻意埋的，用來測它會不會照單全收。

有真正關係的那條邊，準到行號

真的跑了一次，圖建出來後去翻底層的 graph.json：session.py 呼叫 validate_token 這條邊，標記來源是 src/session.py 第 8 行——翻開那一行，真的就是 if not validate_token(token):，一字不差。這條邊的信心分數是最高等級，也確實擔得起。

沒有關係的那對，老實標成「推測」

LRUCache 跟 SlidingWindowCounter 之間，兩邊完全沒有 import 或呼叫，它沒有硬掰出一條「確定關係」，而是標成語意相近、信心等級是推測、分數 0.85。這個分數不是隨便給的——它的規格文件把推測關係的信心分數訂死在幾個固定檔位，0.85 對應的定義是「功能明顯對得上，但沒有直接的符號連結」，剛好精準對上這兩個類別的實際狀況。這條邊的誠實程度，比我原本預期的還要高。

文件裡那句不夠精準的話，被原封不動地當成了事實

真正的落差出現在跟文件有關的那幾條邊。LRUCache 和 SlidingWindowCounter 各自都被標了一條「實作了『固定容量淘汰模式』」的關係，等級是最高等級、信心分數是滿分——跟 session.py 那條真正核對過的程式碼關係，用的是同一個等級。但它的根據，兩條都只寫著「來自 docs/ARCHITECTURE.md」，沒有再往下核對這句話對兩個類別是不是同樣成立。結果就是：文件裡那句對一半、錯一半的描述，被原封不動地複製成了兩條「最高信心」的關係，沒有因為其中一半其實經不起對照而被降級。

「說得出根據」跟「根據是對的」，是兩件事

這張圖沒有騙人——它標的每一條邊，去查都查得到出處，沒有無中生有。但它查到的，是「這句話確實有人寫過」，不是「這句話確實是真的」。源頭是程式碼時，它會老實核對到行號；源頭是一段敘述文字時，它只核對「這段話存不存在」，不會進一步跟程式碼對一遍是否所言不假。對常常要靠它認識一個陌生專案的人來說，這個界線值得記住：如果專案裡的文件是新的、準的，這張圖就跟著準；如果文件已經過時、寫得不夠精確，那份不準確不會被攔下來，會原封不動地變成圖上一條看起來最可信的線。

跟前面幾天放在一起看

這系列前面也測過「規則讀起來很嚴謹、實際運作時留了縫」的例子，但這次的縫不太一樣：它沒有偷懶，也沒有騙人，它只是把誠實的範圍劃在「這句話從哪來」，沒有再往前一步去核對「這句話說得對不對」。知道這條界線畫在哪裡，比直接相信「每條邊都說得出根據」這句話本身更有用。

明天找下一個方向繼續測，候選清單還在累積。